1. Field of the Invention
The present invention relates generally to Java API implementation, and more specifically, to methods and apparatuses for customizing Java API implementations tailored for the specific needs of a given Java application.
2. Description of the Related Art
Java, originally developed by Sun Microsystems, is an object-oriented, multi-threaded, portable, platform-independent, secure programming environment used to develop, test and maintain software programs. Java programs have found extensive use on the World Wide Web, which is the Internet's multimedia information retrieval system. These programs include full-featured interactive, standalone applications, as well as smaller programs, known as applets, that run in a Java-enabled Web browser or applet viewer. In the following description, the term “application” will be used synonymous with the term “applet.”
Java accomplishes platform independence through an intermediate computing state. Java source code is compiled into a machine-independent byte code, which generally is interpreted before being run on a native instruction set of the target processor. The interpretation is done through a Java Virtual Machine (JVM), a software layer that forms a bridge between the byte code and actual hardware. The JVM takes system calls and interprets them into corresponding machine instruction. Java allows developers to use the most productive development environment available, irrespective of platform. Thus, there is no need to develop on the same platform as the target platform or worry about cross-compiling, since a Java program will run on any processor having a JVM.
Java also offers advantages during programming. Memory management is far simpler, and program bugs are fewer, because Java uses references in place of pointers. A reference is an abstract identifier for an object. A reference tags a particular object with a name in the Java Virtual Machine so that the developer may refer to it. At the level of machine code in a CPU, a reference is an address in memory where the address of the object is stored. In this way, the objects can be moved around in memory and only the master pointer needs to be updated rather than all references to the object. This is completely hidden from the Java developer. All memory is dynamically allocated, as a variable is instantiated, but access to individual memory addresses violates the Java security model and is not permitted. Java reclaims memory through automated garbage collection. As memory is allocated, a variable or structure in the language references the memory. The garbage collector searches for unreferenced memory, which it reclaims and adds to the free memory list, releasing developers from memory management worries.
Java is a pure object-oriented language. Every variable is an object in the class hierarchy and has a set of predefined methods, or functions, that can be used to operate it. The object model lets developers define data structures corresponding to real-life objects, making the translation between what a program has to do and how it's implemented transparent.
To concatenate and compress these Java objects, classes, image, audio and other information, Java employs a platform independent file format called a Java archive (JAR) file. One of the main attributes of the JAR file design is to reduce the number of HyperText Transfer Protocol (HTTP) connections that need to be opened, thus reducing download times. For example, FIG. 1 is an illustration showing a prior art network system 100 having Java JAR file 104a and the manner in which the JAR file can be accessed over the Internet. The network system 100 includes a desktop computer 102 coupled to the Internet 106 via a network communication protocol. In the example of FIG. 1, the JAR file 104a includes class files used to create a Java based media player. To access the media player class files, the user computer downloads the JAR file 104a, resulting in the user computer obtaining a copy of the JAR file 104b. The user can then decompress and utilize the classes contained in the JAR file in creating a Java based media player.
However, in many situations, the user does not utilize all the functionality provided by the classes of the JAR file in creating an application based on the JAR file. For example, the user in FIG. 1 may not need to have the functionality to play all the media formats provided by the classes of the JAR file 104b. In this case, the unused classes in the JAR file are wasted. Further, the extra storage needed to store the unused classes and the extra time required to download the unused classes is likewise wasted.
In view of the foregoing, there is a need for techniques that allow a user to customize a JAR file based on the functionality needed by a particular application. The user should be allowed to select the functionality needed without needing to know the exact classes required to allow the selected functionality. Moreover, the resulting customized JAR file should maintain compatibility with the corresponding application program interface (API) associated with the framework of the JAR file.